Object persistence is a mechanism by which an object instance that resides in volatile memory (e.g., random-access memory [RAM], etc.) is mapped to a database, thereby providing permanent storage of the object instance's data. For example, if a source program creates and instantiates a persistent employee object instance, the data associated with the object instance is automatically stored in a database, without any explicit programming. As a result, if a hardware failure were to occur during the execution of a program that processes employee records, the most recent data for the employees would automatically be retained. Object persistence thus provides a mechanism for the permanent storage of data.
Object persistence also provides a mechanism for mapping an object instance's fields to a database, thereby enabling a programmer to (i) retrieve object information from a database without writing explicit database-handling code, and (ii) manipulate objects without having to constantly save changes back to the database. When persistent objects are mapped to a relational database, the mapping mechanism is referred to as object-relational mapping.
FIG. 1 depicts an illustrative object-relational mapping between object class 100 and database schema 110, in accordance with the prior art.
Object class 100 is a class named User that comprises six fields: ssn, lastName, firstName, birthdate, zipCode, and gender. As indicated by the underlined bold typeface, field ssn, which corresponds to social security number, is the key for object class 100 (i.e., each instance of User is uniquely identified by its ssn value).
Database schema 110 is a relation that comprises six attributes: Last, First, SSN (the schema key), Zip, Sex, and DOB.
The dotted arrows in FIG. 1 indicate the object-relational mapping between fields of object class 100 and attributes of database schema 110. As will be appreciated by those skilled in the art, a complete specification of object class 100 and database schema 110 would include data type information for the fields and attributes.
FIG. 2 depicts illustrative object instances 200-1 and 200-2, and illustrative database table 210 in accordance with the prior art.
Object instances 200-1 and 200-2, named user1 and user2, respectively, are instances of object class 100.
Database table 210 is a table in accordance with database schema 110. As shown in FIG. 2, database table 210 comprises rows 220-1 through 220-N, where N is a positive integer.
The arrows in FIG. 2 indicate illustrative object-relational mappings between database table 210 and object instances 200-1 and 200-2. In particular, object instance 200-1 is mapped to table row 220-2, and object instance 200-2 is mapped to table row 220-N, in accordance with the object-relational mapping of FIG. 1. The mapping between an object instance and a table row indicates that either:                (i) the object instance was created (e.g., by a constructor, factory method, etc.) and its field values were then automatically persisted in the table row; or        (ii) the object instance was instantiated with the pre-existing attribute values of the table row.In case (ii), the object instance is instantiated by invoking a finder method that:        (a) takes the value of a key (in this case, a social security number) as an argument, and        (b) instantiates the fields of the object instance with the attribute values of the table row.        
Enterprise JavaBeans is a specification from Sun Microsystems® for both object persistence and transaction processing. In particular, the Enterprise JavaBean (EJB) specification defines entity beans, which are persistent objects that are mapped to a relational database, and session beans, which are used to process transactions and are not persistent.
Entity Beans have at least one primary key that uniquely identifies each bean instance. The primary key can consist of a single field (e.g., social security number, etc.), or a plurality of fields. As an example of the latter, an entity bean for storing sales records might use the social security number of the sales agent in combination with the date/time of the sale as the primary key.
In accordance with the Enterprise JavaBean (EJB) specification, primary keys are immutable—i.e., their value must be specified when an entity bean instance is created, and their value cannot change during the life of the entity bean instance. Entity bean fields that do not belong to a primary key, in contrast, are mutable—i.e., their value can change during the life of the entity bean instance, and they do not have to be initialized when the entity bean instance is created.